cc @xichen01, @ivandika3 Could you please take a look? Thanks!

Thanks @peterxcli for the patch. However, I went back to review the PR for these lines, and it appears they are not related to conditional requests. They were actually added to fix a commit overwrite issue that occurs when multiple S3G instances are writing the same key.

I am concerned that removing them, as I don't think that specific problem has been resolved yet. Could you please provide a bit more detail on why these lines need to be deleted? Thanks!

I cherry-picked the refactor/fix for the test failure to #10224.

the error log is:

2026-05-09 07:21:08,033 [qtp1907241392-109] WARN server.HttpChannel: /bucket-qiyxgiosny/ozone-test-5105985444/ecmultipartKey32
javax.servlet.ServletException: javax.servlet.ServletException: java.lang.NullPointerException: Cannot invoke "org.apache.hadoop.ozone.client.io.KeyDataStreamOutput.setPreCommits(java.util.List)" because the return value of "org.apache.hadoop.ozone.client.io.OzoneDataStreamOutput.getKeyDataStreamOutput()" is null

The root cause of the EC mpu failure is RpcClient#createMultipartStreamKey detected EC and fall back to OzoneOutputStream backed by KeyOutputStream, so getKeyDataStreamOutput got NPE

Thanks @peterxcli for working on this. However, I have some concerns regarding the feasibility of placing this atomic validation within the pre-commit hook. Here are my thoughts:

I believe the original issue stems from scenarios where a timeout occurs due to network instability or other unknown factors(on client side or datanode side), leading to a wrong commit.

Consider this flow: If an exception is thrown during the IO copy process because of timeout, it will jump to the catch block. At this point, the content length validation has not yet been added into the pre-commit hook, meaning the incorrect commit would still proceed.

The original atomic validation was implemented directly within the close() method, ensuring it would be executed regardless of when an exception occurred at any time. Now, it has been moved to a pre-commit hook which was added later. If an exception interrupts the process before this hook is triggered, the validation will be skipped, and an incomplete key might still be committed.

You can try testing one of the specific scenarios provided by @xichen01 for this issue.

Another similar problem:
Ozone can generate an incomplete key.

Reproduce Step:
Ozone S3
Upload the key and interrupt (ctrl + c) the upload before it completes.

An incomplete key will commit

[root@VM-8-3-centos ~]$ aws configure set default.s3.multipart_threshold 1GB
[root@VM-8-3-centos ~]$ aws s3 --endpoint-url http://localhost:9878 cp ~/500M.img s3://bucket1/500M.img

^Ccancelled: ctrl-c received
[root@VM-8-3-centos /tmp]$ aws s3 ls s3://bucket1/ --endpoint-url http://localhost:9878
2023-10-24 15:48:13 121208832 500M.img
AWS S3
Upload the key and interrupt (ctrl + c) the upload before it completes.

the incomplete key will not be committed

[root@VM-8-3-centos ~]$ aws configure set default.s3.multipart_threshold 1GB
[root@VM-8-3-centos ~]$ aws s3 cp ~/500M.img s3://bucket1/500M.img
^Ccancelled: ctrl-c received
[root@VM-8-3-centos ~]$ aws s3 ls s3://bucket1/500M.img
// nothing output

cc @xichen01 As the original implementation by you. Also cc @ChenSammi @kerneltime , as you both reviewed the previous PR. I would love to hear your thoughts on this.

@peterxcli , I think this move to "atomic key creation" logic cannot replace #5524. The key problem is writeToStreamOutput() will throw exception before validateContentLength is set to preCommits. You can double check the stack I shared under https://issues.apache.org/jira/browse/HDDS-9526 comments.

thanks, you're right, checking if the length precommit can be moved before the writeToStreamOutput